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Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Prufungsantrag gem. § 44 PatG ist gestellt 

@ Verfahren und Kommunikationssystem zur Behandlung von Alarmen durch ein mehrere Managementebenen 

aufweisendes Managementnetz 
@ Die Erfindung geht davon aus, daG fur einen Alarmda- 
tenabgleich zwischen einem Agent (AG) einer Manage- 
mentebene (B, C) und zumindest einem Manager (MAI, 
MA2) einer nachsthoheren Managementebene (A, B) die 
Alarmdaten aktiver Alarme ubertragen werden. Erfin- 
dungsgemaB wird von dem Manager (MA1, MA2) eine 
Nachricht (alaAS, alaSC) zu dem Agent (AG) gesendet, 
durch die ein automatischer, von dem Agent wiederholt 
initiierter Alarmdatenabgleich angefordert wird. Eine Kor- 
relationsinformation (aliNI) fur eine Zuordnung der jewei- 
ligen Anforderung zu den vom Agent (AG) nachfolgend 
gesendeten Nachrichten (aINO) wird vom Manager (MAI, 
MA2) empfangen. Der Manager steuert den Alarmdaten- 
abgleich abhangig von zumindest einem zum Agent ge- 
sendeten Parameter. Durch den Erfindungsgegenstand 
kann der Alarmdatenabgleich vom Agent wiederkehrend 
automatisch gestartet werden, wobei er fur den Manager 
gegentiber der Basisfunktionalitat parametrisierbar ist, d. 
h. nicht mehr alle aktiven Alarme mussen zwangslaufig 
vom Agent gesendet werden, sondern nur die durch den 
ubermittelten Parameter naher definierten. Durch die Pa- 
rameter ergibt sich fur den Manager eine Auswahlfunkti- 
on fur eine Teilmenge aus alien Alarmen, die vom Agent 
in periodischen Zeitabstanden von allein geliefert wer- 
den, ohne daft es eines Anstofces durch den Manager be- 
darf. Daraus ergibt sich u. a. eine optimale Nutzung der 
Obergangsressourcen auf der Schnittsteile. 
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Die Erfindung betrifft ein Verfahren sowie ein entspre- 
chendes Komrnunikationssystem zur Behandlung von Alar- 
men durch ein mehrere Management ebenen aufweisendes 
Managementnetz, wobei fur einen Alarmdatenabgleich zwi- 
schen einem Agent einer Managementebene und zumindest 
einem Manager einer nachsthoheren Managementebene die 
Alarmdaten aktiver Alarme ubertragen werden. 

Die Prinzipien eines Managementnetzes, die auch als 
TMN-Prinzipien (Telecommunications Management Net- 
work) bezeichnet werden, definieren mehrere Management- 
ebenen fur das Management eines Kommunikationssystems 
- beispielsweise eines Mobii-Kommunikationssys terns -, 
wobei jede Ebene eine doppelte Funktion hat. Im managen- 
den System, hat jede Ebene aufier der untersten eine Mana- 
ger-Funktion fiir die darunterliegende Ebene. Im gemanag- 
ten System hat jede Ebene auBer der obersten eine Agenten- 
Funktion fur die nachsthohere Ebene. 

Das Fehlermanagement ("Fault Management") ist ein 
wichtigerTeil des TMN-Managements. Grundsatztich spielt 
hier der Agent die aktive Rolle, indem er Fehler der eigenen 
Managementebene rechtzeitig und genau erkennt und an 
den Manager der nachsthoheren Ebene als Alarme ubertragt. 
Die Ubertragung von Alarmdaten vom Agent zum Manager 
ist unkritisch, solange der Kommunikationsmechanismus 
zwischen diesen Systemen nicht gestort ist. Wenn die Ver- 
bindung zwischen den beiden Managementebenen } also 
zwischen Agent und Manager, fiir eine bestimmte Zeit nicht 
mehr gewahrleistet ist, muB der Agent die wahrend dieses 
Intervalls aufgetretenen Alarme zwischenspeichern, um si- 
cherzustellen, daB nach dem Wiederherstellen der Kommu- 
nikationsmoglichkeit dem Manager zum einen moglichst 
schnell eine Ubersicht der z.Zt. aktiven Alarme - z. B. in 
Form einer Liste - zur Verfugung gestellt wird, und der Ma- 
nager zum anderen eine moglichst liickenlose Alarmge- 
schichte ("alarm history") sowohl der aktiven als auch der 
beendeten Alarme ("cleared alarms") aufbauen kann. 

Zu diesem Zweck wird ein Alarmdatenabgleich (alarm 
realignment) zwischen Agent und Manager bei jedem neuen 
Verbindungsaufbau nach einem Verbindungsabbruch oder 
nach einer Initialisierung des Agenten oder des Managers 
ausgefuhrt Alle Alarmdaten aktiver Alarme, zu denen Feh- 
ler im Agent noch nicht behoben sind - erkennbar daran, 
daB sie nicht als "cleared alarms" gekennzeichnet sind -, 
sind daher schnellstrrioglich und vollstandig der nachsthohe- 
ren Managementebene zur Verfugung zu stellen. 

In der alteren Patentanmeldung P 197 52 614.4 sind ein 
derartiges Verfahren und Kommunikauonssystem zur Be- 
handlung von Alarmen angegeben, die eine Basisfunktiona- 
litat fur den Manager zur Anforderung aller Alarme vom 
Agent beschrieben. Dabei sendet der Agent die aktiven 
Alarme als Sequenz standardisierterM-EVENT-REPORTS, 
die in eine zu Anfang von dem Manager initiierte M-AC- 
TION-Request Anforderung und in eine zum Ende von dem 
Agent initiierte M-ACTION-Response Antwort eingebettet 
ist. Dieses sind generische CMISE-standardisierte (Com- 
mon Management Information Service Element) Prbzedu- 
ren, die gemaB ITU-T X.710 definiert sind. Die ITU-T 
X.733 definiert den Inhalt einer standardisierten Alarmiiber- 
tragung (alarm report) die gemaB den M-E VENT-REPORT 
Services durchgefuhrt wird. Alle in Rahmen dieser M-AC- 
TION definierten M- EVENT-REPORTS sind zu def jeweili- 
gen Anforderung durch Venvendung von Korrelationsinfor- 
mationen eindeutig korreliert. Dies erlaubt dem Manager, 
diese M-EVENT-REPORTS einer bestirnmten Anforderung 
zuzuordnen und dariiber hinaus von anderen, "regularen" 
M-E VENT- REPORTS zu unterscheiden. 



Aufgabe der Erfindung ist es, ein Verfahren und Komrnu- 
nikationssystem zur Behandlung von Alarmen durch ein 
mehrere Managementebenen aufweisendes Management- 
netz anzugeben, durch das ein Alarmdatenabgleich zwi- 
5 schen einem Agent und zumindest einem Manager weiter 
verbessert wird. 

Diese Aufgabe wird gemaB der Erfindung hinsichtlich des 
Verfahrens durch die Merkmale des Patentanspruchs 1 und 
hinsichtlich des Kommunikationssystems durch die Merk- 
10 male des Patentanspruchs 15 gelo'st. Weiterbildungen der 
Erfindung sind den Unteranspriichen zu entnehmen. 

Die Erfindung geht davon aus, daB fur einen Alarmdaten- 
abgleich zwischen einem Agent einer Managementebene 
und zumindest einem Manager einer nachsthoheren Ma- 

15 nagement ebene die Alarmdaten aktiver Alarme ubertragen 
werden. ErfindungsgemaB wird von dem Manager eine 
Nachricht zu dem Agent gesendet, durch die ein autpmati- 
scher, von dem Agent wiederhoit initiierter Alarmdatenab- 
gleich angefordert wird. Eine Korrelationsinformatiori fiir 

20 eine Zuordnung der jeweiligen Anforderung zu den vom 
Agent nachfolgend gesendeten Nachrichten mit den Alarm- 
daten wird vom Manager empfangen. Den Alarmdatenab- 
gleich steuert der Manager abhangig von zumindest einem 
zum Agent gesendeten Parameter. 

25 Durch den Erfindungsgegenstand kann der Alarmdaten- 
abgleich vom Agent wiederkehrend automatisch gestartet 
werden, wobei er fur den Manager gegeniiber der Basis- 
funktionalitat parametrisierbar ist, d. h. nicht mehr alle akti- 
ven Alarme mussen zwangslaufig vom Agent gesendet wer- 

30 den, sondern nur die durch den ubermittelten Parameter na- 
her definierten. Durch die Parameter ergibt sich fiir den Ma- 
nager eine Auswahlfunktion fur eine Teilmenge aus alien 
Alarmen, die vom Agent in periodischen Zeitabstanden von 
allein geliefert werden, ohne daB es dafur eines Anstosses 

35 durch den Manager bedarf. Der Manager wird einerseits in 
der Steuerung der Anforderungen entlastet, andererseits be- 
sitzt er die Moglichkeit der steuernden Beeinflussung des 
Abgleichs durch Vergabe der Parameter und unter Anwen- 
dung standardisierter Nachrichten zur Erhohung der Flexibi- 

40 litat des Managers und Reduzierung des Nachrichten- und 
Informationsflusses in erheblichern MaBe. Erst durch die pa- 
rametrisierbare Alignment-Funktionalitat gemaB der Erfin- 
dung konnen beispielsweise eine Priprisierung der Alarme 
und/oder eine aktive Steuerung der Reihenfolge der automa- 

45 tisch vom Agent bereitgestellten Alarme erzielt werden. Be- 
sonders die Kombination der Basisfunktionalitat - Venven- 
dung einer Korrelationsinformation - mit der parametrisier- 
baren automatischen Alignment-FunktionaUtat fuhrt zu ei- 
nem' besonders efifektiven Verfahren und Kommunikations- 

50 system, das eine optimale Nutzung der Ubertragungsres- 
sourcen auf der Schnittstelle der Agent-Manager-Beziehung 
sowie ein schnellstmogliches periodisches Bereitstellen nur 
der vom Manager gewunschten Alarmdaten aktiver Alarme 
fur die nachsthohere Managementebene durch den Agent 

55 bewirkt, 

GemaB einer Weiterbildung der Erfindung werden von 
dem Manager der oder die Parameter in der Nachricht zum 
Alarmdatenabgleich zu dem Agent gesendet. 

GemaB einer anderen Weiterbildung der Erfindung wird 
60 die Nachricht zum automatischen Alarmdatenabgleich von 
dem Manager einzeln fur jede Anforderung zu dem Agent 
gesendet. Auf diese Weise generiert der Manager jedes Mai, 
wenn er ein automatisches Liefem der Alarme in wieder- 
kehrenden Zeitabstanden durch den Agent wunscht, indivi- 
65 duell die Anforderung. 

GemaB einer altemativen Weiterbildung der Erfindung 
wird die Nachricht zum automatischen Alarmdatenabgleich 
von dem Manager fur mehrere Anforderungen gemeinsam 
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zu dem Agent gesendet. Dadurch erfolgt die vom Manager 
gewunschte Parametrisierung des autpmatischen Alarmda- 
tenabgleichs einmalig fur einen langeren Zeitraum und die 
darin enthaltene Einstellung des Managers hat Gultigkeit fur 
den Agent. 

Dabei wird vorzugsweise von dem Agent nach jedem 
durchgefuhrten Alarmdatenabgleich - in einem gesamten 
automatischen Alarmdatenabgleich mit mehreren Wieder- 
holungen - eine Nachricht zum Manager gesendet, mit der 
dem Manager das Ende des einzelnen Alarmdatenabgleichs 
mitgeteilt wird. 

Das periodische automatische Bereitstellen und Senden 
der Alarme durch den Agent erfolgt anhand eines Startzeit- 
punkts und eines Endezeitpunkt fur den gesamten Alarmda- 
tenabgleich sowie eines Zeitintervalls zur Wiederholung des 
jeweiligen Alarmdatenabgleichs, die alle von dem Manager 
in der FJachricht zum Alarmdatenabgleich gesendet werden. 

Um die Flexibility des Managers zu erhohen, wird vor- 
zugsweise von dem Manager zusatzlich eine Zustandsinfor- 
mation zum Agent gesendet, die zum Unterbrechen gesetzt 
und zum Fortsetzen des automatischen Alarmdatenab- 
gleichs riickgesetzt wird. 

GemaB weiterer vorteilhafter Weiterbildungen der Errin- 
dung kann die Parametrisierung mit einem oder mehreren 
der folgenden, von dem Manager jeweils eingestellten Para- 
meterwerten erfolgen. Durch den Parameterwert werden 
vom Agent Alarme angefordert, 

- die von ausgewahlten Agenteinheiten stammen, 

- fur die eine Dringlichkeit angenommen wird, 

- anhand dessen der Agent eine Priorisierung beim 
Senden der angeforderten Alarme nach deren Dring- 
lichkeit, vorzugsweise anhand unterschiedlicher 
Dringlichkeitswerte, vornimmt, 

- die innerhalb eines durch einen Anfangszeitpunkt 
und einen Endzeitpunkt definierten Zeitraum entste- 
hen, 

- anhand dessen der Agent eine Priorisierung beim 
Senden der Alarme nach dem Entstehungszeitpunkt der 
Alarme vornimmt. 

So sieht einebesonders giinstige Ausgestaltung des Erfin- 
dungsgegenstandes vor, daB von dem Agent die Alarmdaten 
der Alarm mit kritischer Dringlichkeit, bei der die Funktio- 
nalitat als nicht mehr gegeben angenommen wird, zuerst 
und die Alarmdaten der Alarme mit unkritischer Dringlich- 
keit, bei der die Funktionalitat als nicht mehr gegeben ange- 
nommen wird, zuletzt automatisch bereitgestellt und gesen- 
det werden. 

Mit der obigen Vorgehensweise kann der Manager die im 
Hinblick auf die Funktionalitat besonders kritischen und da- 
mit fur ihn wichtigen Alarme automatisch, periodisch vom 
Agent gezielt abrufen lassen, und dabei die Schnittstelle 
zum Agent durch den nur auf bestimmte Alarme einge- 
schrankten InformationsfluB gegenuber dem herkommli- 
chen Verfahren der Meldung aller Alarme wesentlich entla- 
sten. 

Nachstehend wird die Erfindung anhand von Ausfuh- 
rungsbeispielen unter Bezugnahme auf die Figuren naher er- 
lautert. Es zeigen 

Fig: 1 das Blockschaltbild eines Managementnetzes fiir 
ein Mobil-Kommunikationssystem mit Agerit-Manager-Be- 
ziehung zwischen einem Betriebs- und Wartungszentrum 
und einem oder mehreren Netzmanagemenlzentren, 

Fig. 2 das Blockschaltbild des Managementnetzes gemaB 
Fig. 1 mit Agent-Manager-Beziehung zwischen einem Ba- 
sisstationssystem und einem Betriebs- und Wartungszen- 
trum zur Durchfuhrung von zumindest zwei Anwendungen 



fiir das Basisstationssystem, 

Fig. 3 das Blockschaltbild von Agent und Manager zur 
Behandlung der Alarme fiir paraDei oder seriell ablaufende 
Alarmdatenabgleiche, 
5 Fig. 4 den NachrichtenfluB zwischen dem Manager und 
dem Agent zur parameterabhangigen Steuerung eines auto- 
matischen Alarmdatenabgleichs individuell fur jede Anfor- 
derung, 

Fig. 5 den NachrichtenfluB nach Fig. 4 fur einen peri- 
10 odisch wiederkehrenden, automatischen Alarmdatenab- 
gleich bei Verwendung eines die Dringlichkeit betreffenden 
Parameterwertes, 

Fig. 6 den NachrichtenfluB zwischen dem Manager und 
dem Agent zur parameterabhangigen Steuerung des automa- 
15 tischen Alarmdatenabgleichs gemeinsam fur mehrere An- 
forderungen, und 

Fig. 7 den NachrichtenfluB nach Fig. 6 fur den periodisch 
wiederkehrenden, automatischen Alarmdatenabgleich bei 
Verwendung des die Dringlichkeit betreffenden Parameter- 
20 wertes. 

Das Ausfuhrungsbeispiel beschreibt die Erfindung an- 
hand eines TMN-Konzepts fiir das Management eines Mo- 
bil-Kommunikationssystems, das bei spiels weise Netzein- 
richtungen eines Mobilfunknetzes nach dem GSM-Standard 
25 aufweist. Die Erfindung ist aber nicht auf Mobilfunknetze 
beschrankt, sondern laBt sich auf Telekommunikationsnetze 
jeder Art, die ein TMN-Managementnetz nutzen, anwenden. 

Ein Mobil-Kommunikationssystem ist ein hierarchisch 
gegliedertes System verschiedener Netzeinrichtungen, bei 
30 dem die unterste Hierarchiestufe von den Mobilstationen 
gebildet wird. Diese Mobilstationen kommunizieren iiber 
eine Funkschnitt stelle mit die nachste Hierarchieebene bil- 
denden Funkstationen, die als Basisstationen bezeichnet 
werden. Die beispiels weise Mobilstationen in einem Funk- 
35 bereich einer Funkzelle versorgenden Basisstationen sind 
vorzugsweise zur Abdeckung eines groBeren Funkgebiets 
zusarnmengefaBt und mit ubergeordneten Netzeinrichtun- 
gen, den Basisstationssteuerungen verbunden. Die Basissta- 
tionen und Basisstationssteuerungen gehoren zu einem Ba- 
40 sisstationssystem (Base Station Subsystem) des Mobil- 
Kommunikadonssystems. Die Basisstationssteuerungen 
kommunizieren iiber definierte Schnittstellen mit einer oder 
mehreren Vermittlungseinrichtungen, den Mobilvermitt- 
lungsstellen, uber die u. a. auch der Ubergang zu anderen 
45 Kommunikationsnetzen erfolgt. Die Mobilvermittlungsstel- 
len bilden gemeinsam mit einer Mehrzahl von Datenbanken 
das Vermittlungssystem (Switching Subsystem) des Mobil- 
Kommunikationssystems. 

Neben den obigen Netzeinrichtungen existieren ein oder 
50 mehrere Betriebs- und Wartungszentren (Operation and 
Maintenance Centers), die u. a. zum Konfigurieren und 
Uberwachen der Netzeinrichtungen dient. Uberwachungs- 
maBnahmen und KonfigurierungsmaBnahmen werden 
hierzu meist vom Betriebs- und Wartungszentrum aus fern- 
55 gesteuert, die iiblicherweise im Bereich der Mobilvermitt- 
lungsstellen angeordnet sind. Ein Betriebs- und Wartungsr 
zentrum kommuniziert dabei jeweils mit einem Basisstati- 
onssystem oder Vermittlungssystem uber eine definierte 
Schnittstelle. Eine weitere Aufgabe des Betriebs- und War- 
60 tungssystems. ist die Durchfuhrung des Konfigurationsma- 
nagements (Configuration Management), das neben dem 
Fehlermanagement einen von fiinf Managementfunktions- 
bereichen darsteilt, die die TMN-Prinzipien identiflzieren. 
Das Konfigurationsmanagement definiert eine Reihe von 
65 Diensten, die eine Anderung der Struktur und darnit des Ver- 
haltens eines Telekommunikationsnetzes durch den Bedie- 
ner ermoglichen. Diese Dienste beziehen sich immer auf In- 
stanzen von gemanagten Objekten, die insgesamt die netz- 
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spezifische Managementinformationsbasis bilden. rnehrfach ausgesendete Anforderungen zum Alarmdatenab- 

Ein gemanagtes Objekt im Sinne des Konfigurationsma- gleich, die im vorliegenden Beispiel parallel zwischen der 

nageraents ist eine logische Abstraktion einer Ressource im Managementebene B, in.der sich der Agent in Form des Be- 

Mobil- Komrnunikationssystem. Hierbei wird unterschieden triebs- und Wartungszentrums OMC1 befindet, und der 

zwischen hardwarebezogenen gemanagten Objekten, die 5 nachsthoheren Managementebene A, in der die Manager 

eine herstellerspezifische Realisierung einer Funktion be- von zumindest zwei Netzrnanagementzentren NMC1, 

schreiben, und funktionsbezogenen gemanagten Objekten, NMC2 gebildet werden, ablaufen. 

bei denen es sich jeweils urn die Abstraktion einer herstel- Urn auch in der Managementebene B, z. B. in dem Be- 
lerunabhangigen Funktionalitat handelt. triebs- und Wartungszentrum OMC1 jederzeit einen Uber- 
Fiir das Management des Mobil-Kommunikationssy- to blick iiber die Fehlersituation sicherzustellen, werden vom 
stems definieren die TMN-Prinzipien mehrere Ebenen ( M Le- Basisstationssystem BSS11 die - auf Grand von beispiels- 
vels"), von denen im vorliegenden Beispiel drei Ebenen un- weise innerhalb der betreuten Basisstationen und Basisstati- 
ter Bezugnahme auf die Fig. 1 und 2 nachfolgend erlautert onssteuerungen auftretenden Fehlem - gespeicherten 
werden. Alarmdaten aktiver Alarme bereitgestellt und parallel zu 
Die Fig. 1 und 2 zeigen jeweils drei Ebenen A, B und C 15 mindestens zwei Managern des Betriebs- und Wartungszen- 
des Managementnetzes, von denen die Managementebene C trums OMC1 in Form der unterschiedlichen Anwendungen 
die Netzeinrichtungsebene ("Network Element Lever 1 ) mit OF1 und OF2, die beide von ein- und derselben physikali- 
mehrerenBasisstationssystemenBSSll,BSSl2...BSSlN schen Einrichtung OMC1 ausgefuhrt werden, gesendet. 
sowie BSS21, BSS22 . . . BSS2M enthalt. Die Manage- Dies erfolgt ebenfalls vorzugsweise nach einem Verbin- 
mentebene B kennzeichnet die Netzeinrichtungsmanage- 20 dungsabbruch oder nach einer Initialisierung des Agenten 
mentebene ("Network Element Management Level"), in der oder des Managers. Eine serielle Ubertragung von rnehrfach 
Betriebs- und Wartungszentren OMC1 und OMC2 jeweils durch einen einzelnen Manager, z. B. dem Betriebs- und 
die herstellerspezifische Managementfunktionalitat fiir ein- Wartungszentrum OMC1, initiierten Anforderungen an den 
zelne Subsysteme, wie im vorliegenden Beispiel das Be- Agent, z. B. dem Basisstationssystem BSS11, ist ebenfalls 
triebs- und Wartungszentrum OMC1 fur die Basisstations- 25 moglich. Altemativ oder zusatzlich kann eine Agent-Mana- 
systeme BSS11, BSS12 . . . BSS1N und das Betriebs- und ger Beziehung auch zwischen dem Betriebs- und Wartungs- 
Wartungszentrum OMC2 fur die Basisstations systeme zentrum OMC1 (ein Agent) und dem Netzmanagementzen- 
BSS21,BSS22 . BSS2M, bereitstellen. Die Management- trum NMC1 (ein Manager) zum seriellen Austausch von 
ebene A kennzeichnet die Netzmanagementebene ("Net- Anforderungen und Alarmdaten oder zum parallelen Aus- 
work Management Level"), in der Netzrnanagementzentren 30 tausch von Anforderungen und Alarmdaten fur mindestens 
NMC1 und NMC2 jeweils eine integrierte, vom Hersteller zwei unterschiedliche Anwendungen NF1 und NF2 (zwei 
unabhangige Management-Funktionalitat realisieren. Dabei Manager) im Netzrnanagementzentrum NMC1 existieren. 
konnen mehrere Netzrnanagementzentren einen Zugriff zu Fig, 2 zeigt die Struktur fur gemaB der Erfindung parallel 
derselben Netzeinrichtung der nachstniedrigeren Manage- ablaufende Alarmdatenabgleiche zwischen der Manage- 
mentebene B haben, im vorliegenden Beispiel die Netzma- 35 mentebene B, in der sich die Manager als Anwendungen 
nagementzentren NMC1 und NMC2 der nachsthoheren Ma- OF1 und OF2 befinden, und der nachstniedrigeren Manage- 
nagement ebene C zum Betriebs- und Wartungszentrum mentebene C, in der sich der Agent befindet. 
OMC1 der nachstniedrigeren Managementebene B. Zwi- Sobald eine in der Managementebene C ausgefallene in- 
schen den Netzeinrichtungen unterschiedlicher Manage- teme Schnittstelle wieder betriebsbereit ist, wird auf Anfor- 
mentebenen sind definierte Schnittstellen zur Informations- 40 derung des Managers/der Manager der Alarmdatenabgleich, 
ubertragung vorgesehen. auch als Realignment-Prozedur oder Realignment- Verfah- 
Der Unterschied in den Darstellungen gemaB den Fig. 1 ren bezeichnet, pararneterabhangig gesteuert und automa- 
und 2 liegt darin, daB eine Agent-Manager-Beziehung zur tisch vom Agent durch wiederholtes Initiieren - vorzugs- 
Behandlung von Alarmen fur einen oder mehrere Alarmda- weise in periodischen Zeitabstanden, die vom Manager ein- 
tenabgleiche in Fig. 1 zwischen dem Betriebs- und War- 45 gestellt und dem Agent mitgeteilt werden - ausgefuhrt. Da- 
tungszentrumOMCl (Agent) und einem Netzmanagement- bei erfolgt der Alarmdatenabgleich im vorliegenden Bei- 
zentrum NMC1 (Manager) oder mehreren - physikalisch spiel zuerst zwischen dem Basisstationssystem, z. B. 
getrennten - Netzrnanagementzentren NMC1, NMC2 (Ma- BSS11, und den Anwendungen OF1, OF2 im Betriebs- und 
nager) sowie in Fig. 2 zwischen dem Basisstationssystem Wartungszentrum OMC1 parallel und setzt sich anschlie- 
BSS1 1 (Agent) und zwei verschiedenen Anwendungen OF1 50 Bend zwischen dem Betriebs- und Wartungszentrum OMC1 
und OF2 (Manager) in dem Betriebs- und Wartungszentrum und den ubergeordneten Netzrnanagementzentren NMC1, 
OMC1 oder zwischen dem Betriebs- und Wartungszentrum NMC2 parallel fort. Am Ende dieser Prozeduren ist die Feh- 
OMC1 (Agent) und zwei verschiedenen Anwendungen NF1 lersituation sowohl im OMC als auch in den NMC wieder 
und NF2 (Manager) in dem Netzrnanagementzentrum aktualisiert. Das Realignment- Verfahren kann selbstver- 
NMC1 besteht. Um in den Netzrnanagementzentren NMC1, 55 standlich auf die Aktualisierung der Alarmdaten zwischen 
NMC2 jederzeit einen Uberblick iiber die Fehlersituation si- Agent und Managern in zwei unmittelbar angrenzenden Ma- 
cherzustellen, werden vom Betriebs- und Wartungszentrum nagementebenen, z. B. Ebene B und Ebene A, beschrankt 
OMC1 die - auf Grund von beispiels weise innerhalb der be- sein. 

treuten Basis stationssysteme BSS11 . . . BSS1N auftreten- Fig. 3 zeigt in schematischer Darstellung den Aufbau von 

den Fehlem - gespeicherten Alarmdaten aktiver Alarme be- 60 Agent AG und Manager MAI , MA2 mit den zur Durchfuh- 

reitgestellt und parallel zu beiden Managern auf Anforde- rung simultan - bei zwei oder mehreren Managern - oder 

rung gesendet. Dies erfolgt vorzugsweise nach einem Ver- seriell - bei nur einem Manager - ablaufender Realignment- 

bindungsabbruch oder nach einer Initialisierung des Agen- Prozeduren erforderlichen Einrichtungen. Jeder Manager 

ten oder des Managers. Ebenso konnen mehrere Anforde- MAI, MA2 und Agent AG verfugt iiber eine Steuereinrich- 

rungen auch hintereinander von einem einzelnen Manager, 65 tung M-CTR bzw. A-CTR, die Nachrichten fur den Alarm- 

z. B. dem Netzrnanagementzentrum NMC1 an den Agent, datenab gleich generieren und auswerten konnen. Ebenso 

z. B. dem Betriebs- und Wartungszentrum OMC1, gerichtet weisen sie - nicht naher dargestellte - Sende/Empfangsein- 

werden. Fig. 1 zeigt die Struktur fur gemaB der Erfindung richtungen fur das Versenden und Empfangen der Nachrich- 
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ten sowie Speichereinrichtungen fur das Speichem der 
Alarmdaten und anderer Nutz- und Signalisierungsinforma- 
tionen auf. 

Die Steuereinrichtungen M-CTR der Manager MAI, 
MA2 generieren jeweils eine Nachricht, die zu dem Agent 5 
gesendet wird und durch die ein automatischer, von dem 
Agent wiederholt initiierter Alarrndatenabgleich angefor- 
dert wird. Dabei enthalten die Nachrichten im Nachrichten- 
fluB eine fur die Zuordnung einer Anforderung zu nachfol- 
gend gesendeten Nachrichten benutzte Korrelationsinfor- 10 
mation, die eindeutig ist. Dariiber hinaus fugen die Einrich- 
tungen M-CTR der Manager MAI, MA2 zur Steuerung des 
automatischen Alarmdatenabgleichs einen oder mehrere Pa- 
rameter par entweder in eine Nachricht, die einzeln fur jede 
Anforderung individuell vom Manager erzeugt und ausge- 15 
sendet wird, oder in eine fur mehrere Anforderungen ge- 
meinsame Nachricht ein. Durch die Angabe eines Start- und 
Endezeitpunkts fur den gesamten Alarrndatenabgleich und 
eines Zeitintervalls zur Definition der Wiederholungszeit- ■ 
punkte zur Ubermittlung von Alarmdaten wird der automa- 20 
tische Alarrndatenabgleich vom Agent periodisch gestartet 
und durchgefuhrt. Das zusatzliche Mitsenden eines oder 
mehrerer Parameter par rnit verschiedenen Parameterwerten 
ermoglicht dem Manager, bestimmte Alarme gezielt vom 
Agent automatisch iibertragen zu lassen. Aus diesem Grund 25 
verfiigt die Einrichtung A-CTR des Agent AG uber eine 
Funktion auto, mit der bei Erreichen des ubermittelten Start- 
zeitpunkts ein Alarrndatenabgleich jeweils begonnen und in 
den Zeitabstanden des vorgegebenen Zeitintervalls bis Er- 
reichen des Endezeitpunkts wiederholt wird. Erst durch die 30 
parametrisierbare Alignment- Funktionalitat gemaB der Er- 
findung konnen beispielsweise eine Priorisierung der 
Alarme und/oder eine aktive Steuerung der Reihenfolge der 
Alarme, die vom Agent automatisch ubermittelt werden 
(Scheduling Funktionalitat), erzielt werden. 35 

Die Steuereinrichtung A-CTR des Agent AG empfangt 
die Nachricht zum automatischen Alarrndatenabgleich mit 
den Parametern par, wertet sie aus, und startet das Real- 
ignment zu den Managem MAI, MA2 durch Rucksenden 
der von den Managern spezifisch angeforderten Alarme an 40 
den vom Manager gesetzten Zeitpunkten. Dabei kann zu- 
satzlich eine Zustandsinformation (administrative State) 
von der Einrichtung M-CTR des Managers MAI, MA2 zum 
Agent AG gesendet werden, die entweder zum Unterbre- 
chen des Alarmdatenabgleichs gesetzt oder zum Fortsetzen 45 
des automatischen Alarmdatenabgleichs riickgesetzt ist. 
Von der Einrichtung M-CTR des Managers MAI, MA2 
wird dariiber hinaus eine eindeutige Korrelationsinforma- 
tion zur Korrelation der jeweiligen Anforderungen generiert 
und zum Agent AG gesendet. Eine Nachricht mit einer wei- 50 
teren Korrelationsinformation zur Zuordnung der nachfol- 
gend vom Agent gesendeten Nachrichten (alarm notificati- 
ons) zu dem jeweils gestarteten Realignment wird ebenfalls 
benutzt. Auch die weitere Korrelationsinformation ist ein- 
deutig. Durch beide Korrelationsinformationen ist eine ein- 55 
deutige Zuordnung simultan oder seriell durchgefuhrter 
Realignments zu mehreren Managern oder einem einzelnen 
Manager moglich. 

Besonders die Kombination der Basisfunktionalitat - Ver- 
wendung der Korrelationsinformationen - rnit der pararne- 60 
trisierbaren Alignment-Funktionalitat fur automatisches Be- 
reitstellen und Ubermitteln von Alarmen fuhrt zu einem be- 
sonders effektiven Verfahren und Kommunikationssystem, 
das eine optimale Nutzung der Ubertragungsressourcen auf 
der Schnittstelle der Agent-Manager-Beziehung sowie ein 65 
schnellstmogliches Bereitstellen nur der vom Manager ge- 
wiinschten Alarmdaten aktiver Alarme fur die nachsthohere 
Managementebene - an definierten Zeitpunkten automa- 



tisch durch den Agent- bewirkt. Ressourcenausnutzung, 
Zeitdauer und Flexibility werden folglich in dem erfin- 
dungsgemaB ausgestalteten Kommunikationssystem gegen- 
uber der Basisfunktionalitat weiter optimiert. 

Wahiweise konnen im Agent AG mehrere, jeweils den 
Managern MAI, MA2 zuordenbare und von ihnen steuer- 
bare Filterfunktionen EFD1, EFD2 (Event Forwarding Di- 
scriminators), mit Filterkriterien fur die vom Agent AG er- 
zeugten Nachrichten mitbenutzt werden, sodaB die Nach- 
richten mit den Alarmdaten nur bei Erfullen der Filterkrite- 
rien zu den Managern MAI, MA2 geroutet werden. Die 
Steuereinrichtung M-CTR des Managers ist in der Lage, 
derartige Filterfunktionen im Agent AG einzurichten, zu 16- 
schen und die Filterkriterien festzulegen, um je nach seinen 
individuellen Anforderungen den NachrichtenfluB steuem 
zu konnen. Daher kann der Fall auftreten, daB die Filter- 
funktions-Einstellung von Manager zu Manager unter- 
schiedlich ist, sodaB durch die simultan ablaufenden Real- 
ignment-Prozeduren inhaltlich verschiedene Alarme mit zu- 
gehorigen Alarmdaten behandelt werden. 

Fig, 4 zeigt den- NachrichtenfluB zwischen einem Agent 
AG - im dargestellten Beispiel gemaB der Fig. 1 dem Be- 
triebs- und Wartungszentrum OMC1 oder im dargestellten 
Beispiel der Fig. 2 dem Basisstationssystem BSS11 - und 
dem Manager MAI, MA2 - im Beispiel gemaB der Fig. 1 
den unterschiedlichen Netzmanagementzentren NMC1, 
NMC2 oder im Beispiel der Fig. 2 den verschiedenen App- 
likationenOFl,OF2. 

Der NachrichtenfluB erfolgt vorzugsweise unter Verwen- 
dung standardisierter M-EVENT-REPORT Nachrichten, der 
eine zu Anfang vom Manager initiierte M-CREATE Anfor- 
derung zum Einstellen der Parameter fur den automatischen 
Alarrndatenabgleich vorangestellt ist. Die M-CREATE An- 
forderung muB vom Manager jedes Mai wieder zum auto- 
matischen Alarrndatenabgleich mit wiederkehrender Uber- 
mittlung von Alarmen an den definierten Zeitpunkten initi- 
iert und dem Agent bekannt gemacht werden. Die Nachrich- 
ten folgen generischen CMISE-standardisierten (Common 
Management Information Service Element) Prozeduren, die 
gemaB ITU-T X.710 definiert sind. Die ITU-T X.733 defi- 
niert den Inhalt einer standardisierten Alarmubertragung 
(alarm report), die gemaB den M-EVENT-REPORT Ser- 
vices durchgefuhrt wird. Die Korrelationsinformationen und 
Parameter werden in die Nachrichten bzw. in bestimmte 
Nachrichtenfelder eingetragen. Des weiteren versehen die 
Manager MAI, MA2 die Parameter zur Steuerung des 
Alarmdatenabgleichs mit bestimmten Parameterwerten und 
tragen sie einzeln oder mehrfach in die jeweilige Anforde- 
rungs nachricht ein. Das Beispiel in Fig. 4 zeigt den Nach- 
richtenfluB nur anhand beispielhafter Nachrichten, wobei 
diese parallel zwischen dem Agent AG und den Managem 
MAI, MA2 oder seriell zwischen dem Agent AG und dem 
einzelnen Manager MAI iibertragen werden konnen. 

Sobald nach einer Unterbrechung der Verbindung die 
Kommunikation zwischen dem Manager MAI, MA2 und 
dem Agent AG wiederhergestellt ist, sendet jeder Manager 
MAI, MA2 die M-CREATE Anforderung mit einer Nach- 
richt alaAS (alarm Alignment Scheduler) zum Agent AG, 
mit der zum automatischen Ubermitteln der Alarmdaten in 
periodischen Zeitabstanden aufgerufen wird. Zu diesem 
Zweck sendet der Manager einen Startzeitpunkt begT und 
einen Endezeitpunkt endT fur den gesamten Alarrndatenab- 
gleich sowie ein Zeitintervall int zur Wiederholung des je- 
weiligen Alarmdatenabgleichs. Zusatzlich wird eine vom 
Manager MAI, MA2 definierte Korrelationsinformation 
alaAH (alarm Alignment Handle) mitgesendet, die eine di- 
rekte Zuordnung der aktuellen M-CREATE-Anforderung zu 
alien nachfolgenden Agent-Nachrichten kennzeichnet. Da- 



DE 198 01 785 A 1 



[0 



mit ist bei mehreren Managern die aktuelle Anforderung 
auch dem jeweiligen Manager zuordenbar, sodaB die paral- 
lelen Realignments der Manager voneinander unabhangig 
initiiert, durchgefuhrt und beendet werden konnen. Des wei- 
teren enthalt die Nachricht alaAS auch eine Zustandsinfor- 
mation admS fur den Agent, die zuvor vom Manager zum 
Unterbrechen des automatischen Alarmdatenabgleichs ge- 
setzt und zum Fortsetzen riickgesetzt werden kann. 

Die Nachricht alaAS enthalt optional auch die vom Ma- 
nager eingetragenen Parameterwerte fiir den nachfolgenden 
Funktionsablauf. Damit wird eine individuelle Funktions- 
ausfuhrung (Action) der parameterabhangigen periodischen 
Ubermittlung der Alarme vom Agent AG angefprdert. Die 
Parametrisierung kann vorzugs weise mit einem oder mehre- 
ren eingestellten Parameterwerten relEN (related Entities), 
relPS (related perceived Severity), priSV (prio severity), 
relTI (related Time Interval), priDT (prio Detection Time) 
erfolgen. Durch den spezifischen Parameterwert werden 
vom Agent Alarme angefordert, 

- die von ausgewahlten Agenteinheiten stammen (re- 
lEN), . 

- fiir die eine Dringlichkeit angenommen wird (relPS), 

- anhand dessen der Agent beim Senden eine Priori- 
sierung der angeforderten Alarme nach deren Dring- 
lichkeit, vorzugsweise anhand unterschiedlicher 
Dringlichkeitswerte (priS V), vomimmt, 

- die innerhalb eines durch einen Startzeitpunkt und 
einen Endzeitpunkt dennierten Zeitraums entstehen 
(relTI), 

- anhand dessen der Agent beim Senden eine Pnon- 
sierung der Alarme nach dem Entstehungszeitpunkt der 
Alarme vomimmt (priDT). 



Die Parameterwerte relEN . . . sind in einem gemaB dem 
Standard vorgegebenen Nachrichtehfeld der Nachricht 
alaAS enthalten, um bereits vorhandene und definierte Fel- 
der fur die Parametrisierung mitbenutzen zu konnen. Eine 
gunstige Variante unter Einbeziehung der Zeit besteht darin, 
daB von dem Agent die Alarmdaten der Alarme mit den al- 
testen Entstehungszeitpunkten zuerst und die Alarmdaten 
der Alarme mit den jungsten Entstehungszeitpunkten zuletzt 
bereitgestellt und gesendet werden. Eine besonders geeig- 
nete Variante der Kombination der Parameterwerte bezug- 
lich Zeit und Dringlichkeit besteht darin, daB von dem 
Agent die Alarmdaten der Alarme mit kritischer Dringlich- 
keit, bei der die Funktionalitat als nicht mehr gegeben ange- 
nommen wird, zuerst und die Alarmdaten der Alarme mit 
unkritischer Dringlichkeit, bei der die Funktionalitat als 
noch gegeben angenommen wird, zuletzt bereitgestellt und 
gesendet werden. 

Im AnschluB an die Auswertung der Parameter in der ein- 
getroffenen Nachricht alaAS startet der Agent AG den 
Alarmdatenabgleich durch Erzeugen einer Nachricht staAA 
(start Alarm Alignment), sobald der vom Manager definier- 
ter Startzeitpunkt begT erreicht ist. Einfugen einer vom 
Agent dennierten Korrelationsinformation aliNI (alignment 
Notification Id) zusammen mit der Korrelationsinformation 
alaAH in die Nachricht staAA ist der nachste Schritt. Die 
vom Agent AG generierte Korrelationsinformation aliNI er- 
moglicht eine direkte Korrelation nachfolgender Alarme zu 
dieser Nachricht staAA. Die Korrelationsinformation aliNI 
ist beispielsweise in dem standardisierten Nachrichtenfeld 
"notification .Identifier" der Nachricht staAA eingetragen. 
Beide Informationen alaAH, aliNI werden gemeinsam in der 
Nachricht staAA vom Agent AG zu den Managern MAI, 
MA2 ausgesendet. Dadurch konnen "alignmentbezogene" 
M-EVENT-REPORT Nachrichten verschiedener M- 



CREATE Anforderungen voneinander unterschieden wer- 
den, aber auch von regularen M-EVENT-REPORT Nach- 
richten, die mit dem Datenabgleich nichts zu tun haben. 
Eine Alignment-Prozedur stoppt namlich nicht zwingend 
5 andere M-EVENT-REPORT Nachrichten, die wahrend der 
Alignment-Prozedur spontan auftreten und an den oder die 
Manager gesendet werden. 

Uber die in der Nachricht alaAS mitgesendete Korrelati- 
onsinformation alaAH lassen sich direkt die folgenden 
10 Nachrichten staAA und alaAS korrelieren, da sie ebenfalls 
die Korrelationsinformation alaAH enthalten. Die Nachrich- 
ten alNO sind uber die Korrelationsinformation aliNI mit 
der Nachricht staAA direkt korreliert. Der jeweilige. Mana- 
ger kann die Nachricht alaAS mit den nachfolgenden Nach- 
15 richten alNO indirekt uber die beiden in der Nachricht 
staAA enthaltenen Korrelationsinformationen alaAH und 
aliNI korrelieren. 

Im AnschluB an den Start des automatischen Alarmdaten- 
abgleichs erfolgt die sukzessive Ubertragung der Alarme 
20 mit den zugehorigen Alarmdaten in aufeinanderfolgenden 
Nachrichten alNO (alarm notification) unter Verwendung 
des M-EVENT-REPORT Service. Dabei weisen die einzel- 
nen Nachrichten alNO jeweils die Korrelationsinformation 
aliNI - beispielsweise in dem dennierten Nachrichtenfeld 
25 "correlated Notifications" - auf. Nach der letzten Meldung 
eines Alarms in einer Sequenz von Nachrichten alNO er- , 
zeugt der Agent AG die Endenachricht endA (end 
Alignment) gemaB dem M-EVENT-S ervice, die ebenfalls 
die Korrelationsinformation aliNI enthalt. Diese Korrelati- 
30 onsinformation ist die vom Manager MAI , MA2 zuvor defi- 
nierte Korrelationsinformation. Fiir den Fall, daB zum je- 
weiligen durch Scheduling" festgelegten Alignment-Zeit- 
punkt keine aktiven Alarme gespeichert sind oder alle 
Alarme vom aktuellen Filter EFD1, EFD2 gesperrt werden, 
35 initiiert der Agent die Nachricht endA unmittelbar nach Er- 
halt der Nachricht staAA. 

Die obige Prozedur des automatischen Alarmdatenab- 
gleichs wird bei jedem neu begonnenen Alignment - abhan- 
gig von dem mitgeteilten Zeitintervall int - wiederkehrend 
40 durchgefuhrt, bis der Endezeitpunkt endT des gesamten 
Alignments erreicht ist. Die Korrelationsinformationen 
alaAH, aliNI dienen der eindeutigen Zuordnung mehrerer 
Anforderungen - moglicher simultaner Realignments zu 
mehreren Managern oder serieller Realignments zu einem 
45 einzelnen Manager. Auch wenn das zu Fig. 4 bechriebene 
Beispiel sich auf parallel Realignments zu mehreren Mana- 
gern bezieht, kann der NachrichtenfluB selbstverstandlich 
auf mehrere, von einem einzigen Manager nacheinander 
ausgeloste Anforderungen angewendet werden, mit dem 
50 Vorteil, daB durch die eindeutige Zuordnung anhand der 
Korrelationsinformationen fur den einzelnen Manager die 
Moglichkeit besteht, die eintreffenden Antworten des Agen- 
ten mit den Alarmdaten auch bei Nichteinhalten der Reihen- 
folge eindeutig den Anforderungen zuordnen zu konnen - 
55 beispielsweise unterschiedlichen Anwendungen im Mana- 
ger. Nacheinander gesendete Anforderungen konnen sich 
gegebenenfalls gegenseitig uberholen, beispielsweise dann, 
wenn zwischen Agent und Manager ein Paketnetz durchlau- 
fen wird. 

60 Fig. 5 zeigt den NachrichtenfluB gemaB Fig. 4 fur einen 
periodisch wiederkehrenden, automatischen Alarmdatenab- 
gleich am Beispiel des die Dringlichkeit betreffenden Para- 
meterwertes priSV. Der Parameterwert priSV nimmt den 
Wert true an, was dem Agent signalisiert, daB er bei der Sen- 
65 dereihenfolge der Alarme nach unterschiedlichen Dringlich- 
keitswerten priorisieren soli. Fiir den Fall, daB der Parame- 
terwert priSV einen anderen Wert (z. B. false) annimmt, ver- 
zichtet der Agent auf die Priorisiemng nach Dringlichkeits- 
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werten. Wird das optional vorhandene Feld vom Manager 
zur Steuerung der angeforderten Alarme erst, gar nicht be- 
nutzt, werden alle aktive Alarme, die eine angenommen 
Dringlichkeit aufweisen, ubertragen (default-Modus). Wei- 
tere Pararneterwerte - siehe Fig. 4 - sind zusatzlich vom 
Manager setzbar. 

Im voriiegenden Beispiel weisen der Startzeitpunkt (Da- 
tum und Zeit) begT den Wert "13.01.1998 12:00:00", der 
Endezeitpunkt endT den Wert "14.01.1998 11:00:00" und 
das Zeitintervall int den Wert "12h" auf. Dies bedeutet, daB 
gezielt nur die Alarme - priorisiert nach deren Dringlichkeit 
(siehe obige Ausfuhrungen) - die zwischen "13.01.1998 
12:00:00" und "14.01.1998 11:00:00" auftreten, gemaB dem 
automatischen Alignment, das alle 12Stunden vom Agent 
wiederholt initiiert wird, vom Agent zur Verfugung gestellt 
und zum Manager gesendet werden. 

Daher wird die Nachricht staAA vom Agent ab einem 
Zeitpunkt evt (event Time) gesendet, sob aid dieser den Wert 
"13.01.1998 12:00:00" erreichuDie folgenden Nachrichten 
alNO enthalten die Alarmdaten der ausgewahlten Alarme 
unter Verwendung des M-EVENT-REPORT Service. Die 
einzelnen Nachrichten alNO weisen neben der Korrelations- 
information aliNI einen Wert fur die Dringlichkeit SV (per- 
ceived Severity) des Alarms auf. Die unterschiedlichen 
Dringlichkeitswerte reichen von "kritisch" cri (critical) iiber 
"wichtig" maj (major), "weniger wichtig" min (minor) bis 
zu "unkritisch" war (warning). Als kritisch wird ein Alarm 
aufgefasst, bei der die Funktionalitat als nicht mehr gegeben 
angenommen wird, wahrend bei einem unkritischen Alarm 
die Funktionalitat als noch gegeben betrachtet wird. Emp- 
fangt der Manager den Dringlichkeitswert war, fasst er die- 
sen Alarm als Warnung beziiglich einer moglichen Beein- 
trachtigung der Funktionen des Agent auf. 

Bei dem eingestellten Parameter priSV beziiglich der 
Dringlichkeit ist der zuerst gemeldete Alarm mit entspre- 
chenden Alarmdaten in der Nachricht alNO als Alarm kriti- 
scher Dringlichkeit, SV=cri, gekennzeichnet. Die nachstfol- 
genden Nachrichten alNO mit Alarmdaten enthalten einen 
Wert SV=maj zur Kennzeichnung eines Alarms mit einer 
wichtigen Dringlichkeit sowie einen Wert SV=rnin zur 
Kennzeichnung eines Alarms mit einer weniger wichtigen 
Dringlichkeit. Die am Ende des automatischen Alignments 
gesendete Nachricht endA zeigt dem Manager an, daB die 
Sequenz von Alarmdaten der im Agent gespeicherten 
Alarme beendet ist. Dabei weist die Nachricht endA die 
vom Agent zuvor zugewiesene Korrelationsinformation 
aliNI auf. 

Ein weiteres Mai startet der Agent autornatisch einen 
Alarmdatenabgleich, sobald der Zeitpunkt evt (event Time) 
den Wert "13.01.1998 24:00:00" annimmt, d. h. das einge- 
stellte Zeitintervall int="12h" fur die Wiederholung erreicht. 
Im folgenden sendet der Agent - analog zu obigen Beispie- 
len - einige Alarmdaten in den Nachrichten alNO, deren 
Sendereihenfolge durch die Dringlichkeitswerte der vorhan- 
denen Alarme bestimmt ist. Das Ende des zweiten Alarmda- 
tenabgleichs erkennt der Manager an der ebenfalls zuietzt 
vom Agent gesendeten Nachricht endA mit entsprechender 
Korrelationsinformation aliNI. Weitere Abgleiche sind in 
dem durch die Werte begT, endT, int eingestellten beispiel- 
haften Zeitfenster nicht vorgesehen. Grundsatzlich konnen 
die vom Agent autornatisch initiierten Abgleiche in kiirze- 
ren Zeitabstanden und damit in einer hoheren Anzahl je 
nach dem vom Manager bestimmten Zeitfenster auftreten. 

Im Gegensatz zu der Einstellung pro M-CREATE Anfor- 
derung zeigt Fig. 6 den NachrichtenfluB zwischen dem Ma- 
nager und dem Agent zur parameterabhangigen Steuerung 
des automatischen Alarmdatenabgleich s durch eine einma- 
iige Einstellung der zeitbezogenen Werte begT, endT, int, 



die fur mehrere anschlieBende Anforderungen gemeinsam 
Gultigkeit behalt. Damit wird in vorteilhafter Weise ein pe- 
riodisches Ubertragen definierter Alarme fur den automati- 
schen Alarmdatenabgleich erzielt, ohne daB es jedes Mai ei- 

5 ner Neueinstellung der obigen zeitbezogenen Werte bedarf. 
Zu diesem Zweck ist der M-EVENT REPORT Nachrichten- 
sequenz - mit den Nachrichten staAA, alNO und endA, 
siehe Beschreibung zu Fig. 4 - eine M-SET Anforderung 
vorangestellt, mit der eine Nachricht alaSC einschlieBlich 

10 der vom Manager optional einfugbaren Parameter relEN, 
relPS, priSV, relTI, priDT als Auswahlkriterien fur die vom 
Agent zu iibertragenden Alarme gesendet wird. Diese optio- 
nalen Parameter konnen unabhangig von den zeitbezogenen 
Werten begT, endT, int von dem Manager geandert werden. 

15 Den Parametem beigestellt ist die Korrelationsinformation 
alaAH. ErfindungsgemaB sind auch die Werte begT fur den 
Startzeitpunkt, endT fur den Endezeitpunkt sowie int fur das 
Zeitintervall zum periodischen Wiederholen des Alarmda- 
tenabgleichs eingetragen. Das Setzen der Zustandsinforma- 

20 tion admST zum Unterbrechen des automatischen Alarmda- 
tenabgleichs und das Rucksetzen der Zustandsinformation 
admST zum spateren Fortsetzen des automatischen Alarm- 
datenabgleichs kann ebenfalls vom Manager durchgefuhrt 
werden. 

25 Fig. 7 zeigt den zur Vorgehensweise von Fig. 6 gehorigen 
NachrichtenfluB bei Einstellung des zu Fig. 5 bereits be- 
schriebenen Parameters priSV. Im Unterschied zu Fig. 5 
werden das durch den Anfangszeitpunkt begT und den En- 
dezeitpunkt endT sowie das Zeitintervall int festgelegte 

30 Zeitfenster und der Parameter priSV - nur in diesem Zeit- 
fenster sollen vom Agent die Alarme nach Dringlichkeit 
priorisiert werden - vom Manager in die Nachricht alaSC 
gemaB der M-SET Anforderung eingefugt und vorab zum 
Agent gesendet. Die Einstellungen behalten fur alle darauf- 

35 folgenden Anforderungsnachrichten ihre Gultigkeit, bis eine 
neue Setznachricht M-SET die bisherigen Parameter und 
das alte Zeitfenster uberschreibt oder fur ungultig erklart. 
Ein weiterer Unterschied betrifft das Zeitfenster, das durch 
den Startzeitpunkt begT=" 16.0 1.1 998 12:00:00", den Ende- 

40 zeitpunkt endT=" 16.01. 1998 22:15:00" und das Zeitinter- 
vall int="6h" vom Manager definiert ist. Dies bedeutet, daB 
gezielt nur die Alarme - priorisiert nach deren Dringlichkeit 
(siehe obige Ausfuhrungen) -, die zwischen "16.01.1998 
12:00:00" und 16.01. 1998 22:15:00" auftreten, gemaB dem 

45 automatischen Alignment, das alle 6 Stunden vom Agent 
wiederholt initiiert wird, vom Agent zur Verfugung gestellt 
und zum Manager gesendet werden. 

Daher wird die Nachricht staAA vom Agent am Zeit- 
punkt evt="16.01.1998 12:00:00" erstmalig gesendet. Die 

50 folgenden Nachrichten alNO enthalten die Alarmdaten der 
ausgewahlten Alarme unter Verwendung des M-EVENT- 
REPORT Service. Die einzelnen Nachrichten alNO weisen 
neben der Korrelationsinformation aliNI den Wert fur die 
Dringlichkeit SV (perceived Severity) des Alarms auf. Bei 

55 dem eingestellten Parameter priS V beziiglich der Dringlich- 
keit ist der zuerst gemeldete Alarm mit entsprechenden 
Alarmdaten in der Nachricht alNO als Alarm kritischer 
Dringlichkeit, SV=cri, gekennzeichnet. Die nachstfolgende 
Nachrichten alNO mit Alarmdaten enthalt den Wert 

60 S V=min zur Kennzeichnung eines Alarms mit einer weniger 
wichtigen Dringlichkeit. Der nachste vom Agent in der 
Nachricht alNO gemeldete Alarm hat den Wert S V=war zur 
Kennzeichnung eines Alarms mit lediglich einer Warnung, 
bei der die Funktionalitat noch als gewahrleistet. angenom- 

65 men ist. Die am Ende des automatischen Alignments an den 
Manager gesendete Nachricht endA weist die vom Agent 
zuvor zugewiesene Korrelationsinformation aliNI auf. 
Ein weiteres Mai startet der Agent autornatisch den 
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Alarmdatenabgleich, sobald der Zeitpunkt evt den Wert 
"16.01.1998 18:00:00" annimmt, d. h. das eingestellte Zeu- 
intervall int="6h" fur die Wiederholung erreicht. Im folgen- 
den sendet der Agent - analog zu obigen Beispielen - einige 
Alarmdaten in den Nachrichten alNO, deren Sendereinen- 5 
folge durch die Dringlichkeitswerte der vorhandenen 
Alarme bestimmt ist. Das Ende des zweiten Alarmdatenab- 
gleichs erkennt der Manager an der ebenfalls zuletzt vom 
Agent gesendeten Nachricht endA mit entsprechender Kor- 
relationsinformation aliNI. Weitere Abgleiche sind in dem 10 
durch die Werte begT, endT, int eingestellten beispielhaften 
Zeitfenster nicht vorgesehen. Grundsatzlich konnen die vom 
Agent automatisch initiierten Abgleiche in kurzeren Zeitab- 
standen und damit in einer hoheren Anzahl je nach dem vom 
. Manager bestimmten Zeitfenster auftreten. * 5 

Patentanspruche 

1. Verfahren zur Behandlung von Alarmen in einem 
Kommunikationssystem durch ein mehrere Manage- 20 
mentebenen (A, B, C) aufweisendes Managementnetz, 
wobei fur einen Alarmdatenabgleich zwischen einem 
Agent (AG) einer Managementebene (B, C) und zu- 
mindest einem Manager (MAI, MA2) einer nachstho- 
heren Managementebene (A, B) die Alarmdaten akti- 25 
ver Alarme iibertragen werden, bei dem 

- von dem Manager (MAI , MA2) eine Nachricht 
. (alaAS, alaSC) zu dem Agent (AG) gesendet 

wird, durch die ein automatischer, von dem Agent 
(AG) wiederhoit initiierter Alarmdatenabgleich 30 
angefordert wird, 

- von dem Manager (MAI, MA2) eine Korrelati- 
onsinformation (aliNI) fur eine Zuordnung der 
Anforderung zu den vom Agent (AG) nachfol- 
gend gesendeten Nachrichten (alNO) mit den 35 
Alarmdaten empfangen wird, und 

- von dem Manager (MAI, MA2) der automati- 
sche Alarmdatenabgleich abhangig von zumin- 
dest einem zum Agent (AG) gesendeten Parame- 
ter (par) gesteuert wird. 40 

2. Verfahren nach Anspruch 1, bei dem von dem Ma- 
nager (MAI , MA2) der oder die Parameter (par) in der 
Nachricht (alaAS, alaSC) zum automatischen Alarm- 
datenabgleich gesendet werden. 

3. Verfahren nach Anspruch 1 oder 2, bei dem die 45 
Nachricht (alaAS) zum automatischen Alarmdatenab- 
gleich von dem Manager (MAI, MA2) einzeln fur jede 
Anforderung zu dem Agent (AG) gesendet wird. 

4. Verfahren nach Anspruch 1 oder 2, bei dem die 
Nachricht (alaSQ zum automatischen Alarmdatenab- 50 
gleich von dem Manager (MAI, MA2) fur mehrere 
Anforderungen gemeinsam zu dem Agent (AG) gesen- 
det wird. 

5. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem von dem Agent (AG) nach jedem durch- 55 
gefuhrten Alarmdatenabgleich eine Nachricht (endA) 
zum Manager (MAI, MA2) gesendet wird, mit der 
dem Manager (MAI, MA2) das Ende des jeweiligen 
Alarmdatenabgleichs mitgeteilt wird. 

6. Verfahren nach einem der vorhergehenden Ansprii- 60 
che, bei dem von dem Manager (MAI, MA2) in der 
Nachricht (alaAS, alaSC) zum automatischen Alarm- 
datenabgleich ein Startzeitpunkt (begT) und ein Ende- 
zeitpunkt. (endT) fiir den gesamten Alarmdatenab- 
gleich sowie ein Zeitintervall (int) zur Wiederholung 65 
des jeweiligen Alarmdatenabgleichs gesendet werden. 

7. Verfahren nach Anspruch 6, bei dem von dem Ma- 
nager (MAI, MA2) zusatzlich eine Zustandsinforma- 



tion (admST) zum Agent (AG) gesendet wird, die zum 
XJnterbrechen des automatischen Alarmdatenabgleichs 
gesetzt und zum Fprtsetzen ruckgesetzt wird. 

8. Verfahren nach einem der vorhergehenden Anspru- 
che, bei dem ein Parameter (par) von dem Manager 
(MAI, MA2) mit einem Parameterwert (relEN) verse- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, die von ausgewahlten Agenteinheiten 
stammen. 

9. Verfahren nach einem der vorhergehenden Ansprii- 
che, bei dem ein Parameter (par) vori dem Manager 
(MAI, MA2) mit einem Parameterwert (relPS) verse- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, fur die eine Dringlichkeit angenommen 
wird. 

10. Verfahren nach Anspruch 9, bei dem von dem Ma- 
nager (MAI, MA2) ein zusatzlicher Parameterwert 
(priPS) benutzt wird, anhand dessen der Agent (AG) 
eine Priorisierung beim Senden der angeforderten 
Alarme nach deren Dringlichkeit vomimmt. 

. 11. Verfahren nach Anspruch 10, bei dem der Agent 
(AG) die Priorisierung der zu dem Manager (MAI, 
MA2) zu ubertragenden Alarme nach unterschiedli- 
chen Dringlichkeitswerten (cri, maj, min, war) vor- 
nimmt 

12. Verfahren nach einem der vorhergehenden An- 
spruche, bei dem ein Parameter (par) von dem Manager 
(MAI, MA2) mit einem Parameterwert (relTI) verse- 
hen wird, durch den vom Agent (AG) Alarme angefor- 
dert werden, die innerhalb eines durch einen Anfangs- 
zeitpunkt (inst) und einen Endzeitpunkt (inen) definier- 
ten Zeitraum entstehen. 

13. Verfahren nach einem der vorhergehenden An- 
spriiche, bei dem von dem Manager (MAI, MA2) ein 
zusatzlicher Parameterwert (priDT) benutzt wird, an- 
hand dessen der Agent (AG) eine Priorisierung beim 
Senden der Alarme nach dem Entstehungszeitpunkt 
(evT) der Alarme vornimmt. 

14. Verfahren nach Anspruch 13, bei dem von dem 
Agent (AG) die Alarmdaten der Alarme mit kritischer 
Dringlichkeit, bei der die Funktionalitat als nicht mehr 
gegeben angenommen wird, zuerst und die Alarmdaten 
der Alarme mit unkritischer Dringlichkeit, bei der die 
Funktionalitat als noch gegeben angenommen wird, 
zuletzt automatisch bereitgestellt und gesendet werden. 

15. Kommunikationssystem zur Behandlung von 
Alarmen durch ein mehrere Managementebenen (A, B, 
O aufweisendes Managementnetz, wobei fur einen 
Alarmdatenabgleich zwischen einem Agent (AG) einer 
Managementebene (z. B. B) und zumindest einem Ma- 
nager (MAI, MA2) einer nachsthoheren Management- 
ebene (z. B. A) die Alarmdaten aktiver Alarme iibertra- 
gen werden, 

- Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fur das Senden einer Nachricht 
(alaAS, alaSc) zu dem Agent (AG) gesendet wird, 
durch die ein automatischer, von dem Agent (AG) 
wiederhoit initiierter Alarmdatenabgleich ange- 
fordert wird, 

- Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fur das Empfangen einer Korrelati- 
onsinformation (aliNI) fur eine Zuordnung der je- 
weiligen Anforderung zu den vom Agent (AG) 
nachfolgend gesendeten Nachrichten (alNO) mit 
den Alarmdaten, und 

- Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) fur eine Steuerung des Alarmdaten- 
abgleich abhangig von zumindest einem zum 
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Agent (AG) gesendeten Parameter (par). 

16. Kommunikationssy stern nach Anspruch 15, bei 
dem die Einrichtungen (M-CTR) in dem Manager 
(MAI, MA2) den oder die Parameter (par) in jede An- 
forderungsnachricht (repAA) einfiigen. 5 

17. Kommunikationssystem nach Anspruch 15 oder 
16, bei dem die Einrichtungen (M-CTR) in dem Mana- 
ger (MAI, MA2) die Nachricht (alaAS) zum automati- 
schen Alarmdatenabgleich einzeln fur jede Anforde- 
rung zu dem Agent (AG) senden. 1° 

18. Kommunikationssystem nach Anspruch 15 oder 
16, bei dem die Einrichtungen (M-CTR) in dem Mana- 
ger (MAI, MA2) die Nachricht (aiaSQ zum automati- 
schen Alarmdatenabgleich gemeinsam fur mehrere 
Anforderungen zu dem Agent (AG) senden. 15 

19. Kommunikationssystem nach einem der Ansprii- 
che 15 bis 18, bei dem die Einrichtungen (M-CTR) in 
dem Manager (MAI, MA2) in die Nachricht (alaAS, 
alaSC) zum automatischen Alarmdatenabgleich einen 
Startzeitpunkt (begT) und einen Endezeitpunkt (endT) 20 
fur den gesamten Alarmdatenabgleich sowie ein Zeit 
intervall (int) zur Wiederholung des jeweiligen Alarm- 
datenabgleichs einfiigen. 

20. Kommunikationssystem nach einem der Ansprii- 
che 15 bis 19, bei dem von dem Manager (MAI, MA2) 25 
ein Parameter (par) rnit einem Parameterwert (relEN) 
versehen ist, durch den vom Agent (AG) Alarme ange- 
fordert werden, die von ausgewahlten Agenteinheiten 
stammen. 

21. Kommunikationssystem nach einem der Anspru- 30 
che 15 bis 20, bei dem ein Parameter (par) von dem 
Manager (MAI, MA2) mit einem Parameterwert 
(relPS) versehen ist, durch den vom Agent (AG) 
Alarme angefordert werden, fiir die eine Dringlichkeit 
angenommen wird. 35 

22. Kommunikationssystem nach. Anspruch 21, bei 
dem von dem Manager (MAI, MA2) ein zusatzlicher 
Parameterwert (priPS) benutzt ist, anhand dessen der i 
Agent (AG) eine Priorisierung beim Senden der ange- 
forderten Alarme nach deren Dringlichkeit vomimmt. 40 

23. Kommunikationssystem nach einem der Ansprii- 
che 15 bis 22, bei dem ein Parameter (par) von dem 
Manager (MAI, MA2) mit einem Parameterwert 
(relTI) versehen ist, durch den vom Agent (AG) 
Alarme angefordert werden, die innerhalb eines durch 45 
einen Anfangszeitpunkt (inst) und einen. Endzeitpunkt 
(inen) definierten Zeitintervalls entstehen. 

24. Kommunikationssystem nach einem der Ansprii- 
che 15 bis 23, von dem Manager (MAI, MA2) ein zu- 
satzlicher Parameterwert (priDT) benutzt ist, anhand 50 
dessen der Agent (AG) eine Priorisierung beim Senden 
der Alarme nach dem Entstehungszeitpunkt (evT) der 
Alarme vornirnmt. 
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